Open in Stackblitz

pnpm add https://pkg.pr.new/mmkal/expect-type@126

commit: ab2cff4

I see b?: number as problem. Imagine having a type with b?: number and updating it to b: number. I would like to see a failing test just like with:

expectTypeOf<Pick<MyType, "a" | "b">>().toEqualTypeOf<{readonly a: string; b?: number}>() // fail

Also not sure if this was intended, because documentation says: "This is a strict check, but only on the subset of keys that are in both types." Or I missed something?

Yep, optional properties are checked too. All the goodness from toEqualTypeOf, it's basically equivalent to manually doing Pick. Have updated the comment in the body. What do you think the docs should say to explain it better?

More examples below, all work as expected. I might see what some other people think of this change before adding a few more tests to make clearer what it does.

type MyType = {readonly a: string; b: number; c: {some: {very: {complex: 'type'}}}; d?: boolean}

expectTypeOf<MyType>().toMatchObjectType<{a: string; b: number}>() // fails - forgot readonly
expectTypeOf<MyType>().toMatchObjectType<{readonly a: string; b?: number}>() // fails - b shouldn't be optional
expectTypeOf<MyType>().toMatchObjectType<{readonly a: string; d: boolean}>() // fails - d should be optional

expectTypeOf<MyType>().toMatchObjectType<{readonly a: string; b: number}>() // passes
expectTypeOf<MyType>().toMatchObjectType<{readonly a: string; d?: boolean}>() // passes

type BinaryOp = {
  (a: number, b: number): number
  (a: bigint, b: bigint): bigint
}

type Calculator = {add: BinaryOp; subtract: BinaryOp}

expectTypeOf<Calculator>().toMatchObjectType<{add: BinaryOp}>()
expectTypeOf<Calculator>().toMatchObjectType<{subtract: BinaryOp}>()
expectTypeOf<Calculator>().toMatchObjectType<{add: BinaryOp; subtract: BinaryOp}>()

expectTypeOf<Calculator>().toMatchObjectType<{add: {(a: number, b: number): number; (a: bigint, b: bigint): bigint}}>()

expectTypeOf<Calculator>().toMatchObjectType<{add: (a: number, b: number) => number}>() // fails - only one overload
expectTypeOf<Calculator>().toMatchObjectType<{add: (a: bigint, b: bigint) => bigint}>() // fails - only one overload

(also, noticed you're working on something similar https://github.com/tstyche/tstyche - looks nice! have you had a similar decision to make there?)

Ah.. There was a typo. Got it. As you noticed somewhere: it is hard to explain what 'match' means in type context. For me it feels like Pick is familiar and clear. I was simply wondering about your opinion.

(Yes, I had .toMatch in TSTyche. It is deprecated in favour of Pick / Omit. By the way, only the surface looks similar. Yes, expect() API is somewhat familiar, but types are compared programatically like in tsd. Only that the install size of TSTyche is just above 220kB.)

@mmkal Can .toExtend() be negated?

edit: nvm just saw that it can.

Is .toExtend() basically the same as .toMatchTypeOf()? Is it an attempt to rename it to something less confusing or is it stricter as well?

Is .toExtend() basically the same as .toMatchTypeOf()? Is it an attempt to rename it to something less confusing or is it stricter as well?

Yes it's the same. toMatchTypeOf would be deprecated by this change

Update - it's now a "deep" pick, to match jest's toMatchObject. That enables this kind of thing:

const user = {
  email: 'a@b.com',
  name: 'John Doe',
  address: {street: '123 2nd St', city: 'New York', zip: '10001', state: 'NY', country: 'USA'},
}

expectTypeOf(user).toMatchObjectType<{name: string; address: {city: string}}>()

It also differentiates it vs a simple usage of Pick<...> - that would only work for top-level properties.